Conventional database management systems (DBMS) contain “system tables” that hold object definitions for tables, fields, indexes, and the like. However, the scope of the conventional object definitions does not expand beyond the database tier. Moreover, the conventional database management systems (DBMS) do not conceal the proprietary language and syntax of any database management systems (DBMS) utilized as a backend repository.
Examples of problems with conventional architectures for conventional database management systems (DBMS) include relationship types and relationship examples. For example, concerning relationship types, conventional system tables do a good job of storing information about tables, fields, and indexes, and the like. This information has proven beneficial when developing the application programming interface (API) tier and graphic user interface (GUI) tier. There are some limitations, however, when it comes to information about the classes and attributes in the application programming interface (API) tier and how the classes and attributes relate to tables and fields in the database (DB) tier. For example, there are two relationships between database (DB) objects and application programming interface (API) objects currently modeled in a conventional architecture. The first relationship is the link between a class and the table the class represents. The second relationship is the link between an attribute and the field the attribute represents. Storing the class and attribute values in a field record indicates that these class-table and attribute-field relationships are one-to-one, when in reality the relationships are many-to-one. Similar concerns exist for relationship examples.